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METHOD AND SYSTEM FOR PROVIDING INTERACTIVE 
CARDHOLDER REWARDS IMAGE REPLACEMENT 

BACKGROUND OF THE INVENTION 
5 [0001] The present invention generally relates to card image replacement and, more 

specifically, to a method and system for managing card image replacement on a token via a 
computer network. 

[0002] The emergence of secured tokens, such as smartcards, has allowed a much 

higher volume of information to be stored on a transaction card. For instance, in addition to 
10 the typical cardholder information, a smartcard is able to store a variety of different programs 
including, for example, a loyalty program of which the cardholder is a participant. 
Furthermore, unlike cards with magnetic stripes which can only retain static information, the 
use of a smartcard allows information stored thereon to be changed dynamically. As a result, 
there is often a need to update or replace contents of a smartcard. 

15 [0003] Moreover, smartcards often need to be replaced for any number of reasons. 

Due to the transit time needed for replacement cards to reach their respective cardholders, 
these cards (such as a chip card that has the capability to receive updated information) 
generally do not contain the latest transaction information. This is because transactions 
conducted with the old card often occur during the transit period, i.e., the period between the 

20 issuance of the replacement card and the actual receipt of that card by its owner. 

[0004] There are many different situations in which replacement cards are needed. 

One common situation is when an old card is about to expire. Typically when issuers, such 
as banks, replace a card, they do so by sending a replacement card to the cardholder in 
advance of the expiration date. Once the replacement card has been personalized and sent for 

25 delivery to the cardholder, there is a period of time that the cardholder may be conducting 
transactions on his/her existing card. In the case of a chip card, a cardholder may make 
transactions that result in information being stored on the chip during the time the 
replacement card is in transit. As a result, when the replacement card is delivered to the 
cardholder, the most recent transaction information would not be captured on the replacement 

30 card. 
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[0005] Another common situation in which a replacement card is desired is when a 

card has been lost or stolen. Similar to the situation described above, the replacement card 
would not contain the most recent transaction information. Furthermore, in the case of lost or 
stolen cards, unauthorized and/or illegal transactions may have occurred. Therefore, it would 
5 be important to include the correct authorized transaction information on the replacement 
card. 

[0006] Under conventional practice, a replacement card does not always contains the 

latest information that the cardholder desires. Sometimes, the latest information that the 
cardholder wishes to store on the replacement card may not be available. For example, in 

10 existing card-based, offline loyalty programs, when an issued card reaches its expiration date, 
a new (replacement) card is typically sent to the cardholder in advance, normally one month 
prior to expiration. Activities continue on the old card while the new card is being prepared 
and mailed to the cardholder. In order to prepare the new card, the old card status is utilized 
when personalizing the new card, enabling the new card to be functional when it is delivered 

1 5 to the cardholder. During the period of time after the new card is prepared and the date when 
the cardholder receives the replacement (new) card, the cardholder may conduct incremental 
reward transactions using his/her old card, thereby causing the image stored within the old 
card to be updated and, therefore, out of sync with the image personalized on the new card. 
As a result, when the cardholder attempts to utilize the new card, one or more earned rewards 

20 may have been lost entirely or reward accumulations may have been lost, causing customer 
dissatisfaction and confusion. 

[0007] Hence, it would be desirable to provide a method and system that is capable of 

facilitating card image replacement so as to allow replacement cards to be updated with the 
latest accurate transaction information in an intelligent and efficient manner. 

25 

BRIEF SUMMARY OF THE INVENTION 
[0008] A system for facilitating image management for portable devices is disclosed. 

The system includes a host configured to maintain information relating to a first portable 
device and a second portable device and an interface device configured to communicate with 
30 the host and the first and second portable devices. The interface device includes control logic 
configured to: determine whether the first portable device is valid for image synchronization 
using information provided by the host; and if it is determined that the first portable device is 
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valid for image synchronization, record an image of the first portable device, determine 
whether the second portable device is valid for image synchronization, and download an 
image of the first portable device to the second portable device if it is determined that the 
second portable device is valid for image synchronization. 

5 [0009] The interface device further includes control logic configured to: determine 

whether the second portable device is valid for image replacement using information 
provided by the host, and if it is determined that the second portable device is valid for image 
replacement, retrieve an image of the first portable device and download the retrieved image 
to the second portable device. 

10 [0010] The interface device also includes control logic configured to: determine 

whether the second portable device includes additional information that is not included in the 
image of the first portable device, and if it is determined that the second portable device 
includes the additional information, concatenate the additional information with the image of 
the first portable device, and download the concatenated additional information and image of 

15 the first portable device onto the second portable device. The interface device concatenates 
the additional information and the image of the first portable device based on a set of conflict 
resolution rules. 

[001 1] The present invention provides a number of advantages and benefits. For 

example, a cardholder would have more incentive to transfer his/her reward information to a 

20 new smartcard which, in turn, results in better customer satisfaction since the cardholder is 
able to more easily reap the rewards of his/her participation in loyalty programs. Most 
current loyalty programs maintain rewards through back-end systems and have longer 
duration such as annual expiration dates or greater, which does not impact card reissue. Card 
reissue provides a smartcard with an account number only. The real time concatenation and 

25 transfer of reward and multiple program information provided by the present invention 

becomes more relevant due to the numerous reward programs stored on one smartcard with 
varying expiration dates of potentially short duration. 

[0012] Also, in most paper-based reward systems, the loss of a paper-based reward 

means the loss of the reward. The present invention allows rewards to be retained even if the 
30 smartcard that carries the current information relating to a reward program has been lost. 
This again results in better customer satisfaction since the cardholder will not feel that s/he 
has unjustly lost his/her rewards due to a lost or stolen smartcard. 
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[0013] Reference to the remaining portions of the specification, including the 

drawings and claims, will realize other features and advantages of the present invention. 
Further features and advantages of the present invention, as well as the structure and 
operation of various embodiments of the present invention, are described in detail below with 
5 respect to accompanying drawings, like reference numbers indicate identical or functionally 
similar elements. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0014] FIG. 1 is a simplified schematic diagram illustrating one exemplary 

1 0 embodiment of the present invention; and 

[0015] FIGs. 2A and 2B are flowcharts illustrating exemplary operations of one 

embodiment of the present invention. 



DETAILED DESCRIPTION OF THE INVENTION 
1 5 [001 6] The present invention in the form of one or more exemplary embodiments will 

now be described. FIG. 1 is a simplified schematic diagram illustrating one exemplary 
embodiment of the present invention. In this exemplary embodiment, the system 100 
includes a portable device creation module 102, a host 104, a communication medium 106, 
an interface device 108, a cardholder selection interface 1 10 and a portable device 112. 

20 [0017] The host 104 can be any kind of computing device, such as, a server or the 

like. The host 104 cooperates with the portable device creation module 102 to create the 
portable device 1 12 for use in the system 100. The host 104 communicates with the interface 
device 108 via the communication medium 106. The communication medium 106 may be 
any kind of communication network, including but not limited to the Internet, a local area 

25 network (LAN), a wide area network (WAN), and a wireless network, etc. The interface 

device 108, in turn, communicates with the portable device 1 12 via the cardholder selection 
interface 1 10 to allow images to be replaced or updated on the portable device 1 12, as will be 
further described below. The interface device 106 can be, for example, a kiosk, a fixed 
workstation or a website, that is designed to allow a user to communicate with the host 104 to 

30 perform various functions as further described below. The portable device 1 12 includes 
smartcards, cellular phones, personal digital assistants (PDAs), pagers, payment cards, 
security cards, access cards, smart media, transponders, and the like. 
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[0018] In one exemplary application, the system 100 is deployed in connection with a 

loyalty/reward program. The system 100 allows a cardholder to activate image replacement 
for his/her smartcards. The system 100 includes a control application (or set of software 
components) residing within a kiosk or on a website that allows the cardholder to request and 
5 initiate synchronization of the rewards program images (RPIs) residing respectively on two 
smartcards that are in the possession of the cardholder. The first smartcard is an existing 
smartcard that is currently used by the cardholder for transactions associated with a loyalty 
program, and the second smartcard is a new smartcard that is sent to the cardholder. The 
second smartcard may be sent to the cardholder for a number of reasons including, for 
10 example, replacing the first smartcard or allowing the cardholder to have multiple smartcards 
for his/her use. 

[0019] More specifically, the system 100 includes a card merge module (CMM) that 

enables the upload and/or download of card images to and from a smartcard, an application or 
applet on a smartcard capable of interacting with the kiosk or website, and appropriate user 
1 5 interface and device driver software. 

[0020] When the cardholder visits the kiosk or website and selects the RPI 

synchronization option, the CMM performs the following functions where appropriate. First, 
the CMM authenticates a first (existing) smartcard supplied by the cardholder. The CMM 
also checks with the host 104 to determine if synchronization with the first smartcard is 
20 allowed. The host 104 maintains information relating to the number of synchronizations that 
can be performed for a smartcard or an account associated with the smartcard. In a situation 
where only one synchronization is allowed, if a previous synchronization has already been 
performed, then the CMM disallows the requested synchronization. 

[0021] If synchronization is permitted, the CMM then further performs the following. 

25 The RPI of the first smartcard is recorded. The CMM then instructs the cardholder to insert 
the second (new) smartcard into a card acceptance device or card reader coupled to the kiosk 
or website. The second smartcard is then authenticated. As mentioned above, the second 
smartcard is sent to the cardholder for any one of a number of reasons. The host 104 
maintains information relating to the second smartcard that is sent to the cardholder, thereby 

30 allowing authentication to be performed. Once the second smartcard is authenticated, the 

previously recorded RPI of the first smartcard is downloaded to the second smartcard. Where 
appropriate, the CMM may contact the host 104 to retrieve additional information, such as 
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transaction history, for downloading to the second smartcard. The CMM then confirms the 
successful synchronization. 

[0022] According to another exemplary aspect, the system 100 may also be used to 

provide RPI replacement for a new smartcard that has been issued as a replacement for a lost, 
5 stolen or damaged smartcard. In this situation, upon the cardholder selecting the RPI 

replacement option, the CMM performs an RPI replacement. The cardholder may provide 
the requisite information to allow the CMM to perform the RPI replacement. More 
specifically, the CMM first checks with the host 104 to determine if the requested RPI 
replacement is allowed. If the RPI replacement is allowed, the CMM then performs an online 

10 query to a central database for the purpose of downloading the most current copy of the RPI 
for the old smartcard. In one implementation, the query to the central database is effected 
through the host 104. Where appropriate, the CMM may also contact the host 104 to retrieve 
additional information. Once the copy of the desired RPI (and any additional information) is 
retrieved, the copy is stored by the CMM. The CMM then prompts the cardholder to insert 

15 the second the new replacement smartcard into the card acceptance device or card reader. 

The new replacement smartcard is then authenticated. If the authentication is successful, the 
CMM downloads a copy of the previously stored RPI and additional information, if 
appropriate, onto the new replacement smartcard and confirms the successful download. 

[0023] As mentioned above, the CMM has the ability to evaluate and block the 

20 requested RPI synchronization or RPI replacement if such synchronization or replacement is 
not allowed. 

[0024] In addition, the system 100 may further be used to provide a concatenation or 

merge of information between two smartcards during either the synchronization or 
replacement process. 

25 [0025] Information from the new smartcard, the old smartcard and the host 104, 

where appropriate, is concatenated when information from the foregoing three entities do not 
overlap. In other words, corresponding information from the three entities, where 
appropriate, is combined to build the proper transaction history on the new smartcard. As 
will be discussed below, concatenation of information may be subject to conflict resolution 

30 rules or logic. 

[0026] Information from the new smartcard, the old smartcard and the host 104, 

where appropriate, is merged when there is some overlap of information from the foregoing 
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three entities. For example, all three entities may have different information relating to 
program accumulators or counters for the same loyalty program. Merging of information 
may include one or more of the following: merging two or more values to create a new value; 
and providing choices to the cardholder to, for example, select which program(s) s/he wants 
5 to delete or retain, merge or copy without change, choose not to install a program and merge 
programs that are unrelated. 

[0027] In one illustrative example, the CMM has the ability to determine if the new 

smartcard has been used to perform any rewards transactions prior to its presentation for RPI 
synchronization or replacement. If the new smartcard has been used for transactions 

10 (meaning that the new smartcard contains new information that is not available on the old 
smartcard), then the CMM compares the respective RPIs on the old and the new smartcards 
to detect any differences. The detected differences represent new information that is on the 
hew smartcard but not on the old one. The CMM then downloads a copy of the desired RPI 
(which generally is a copy of the RPI from the old smartcard) onto the new smartcard. Next, 

15 the CMM updates the new smartcard based on the detected differences to ensure that the new 
information previously stored on the new smartcard prior to its synchronization or 
replacement is restored and retained. For example, the CMM may add any rewards programs 
from the old RPI that are not present within the new RPI; and the CMM may update rewards 
programs that exist in both versions of the RPIs by summing the results of both (i.e., adding 

20 the redemptions and accumulation counters of both RPIs and recording the sum of both on 
the RPI of the new smartcard). 

[0028] It should be understood that the concatenation or merge of information 

between two smartcards as described above can be performed according to one or more sets 
of predetermined conflict resolution rules or logic. For example, there may not be sufficient 

25 memory capacity on the new smartcard to store the old RPI from the old smartcard as well as 
the new information on the new smartcard. In this situation, the CMM may consult certain 
rules to eliminate information to accommodate the limited memory capacity of the new 
smartcard. For instance, the most recent information is retained first, which conversely 
means the oldest information is eliminated first. In another example, the respective RPIs 

30 from the new and the old smartcards may contain conflicting information. Similarly, the 

CMM may consult certain rules to resolve any such conflict. The rules and/or logic that can 
be used to provide the merge or concatenation of information as described above may take on 
many different forms depending on the specific applications. In some situations, input or 
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selections may be requested from the cardholder to resolve any conflicts. Based on the 
disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate 
how to design the desired rules and/or logic to implement the foregoing functions in 
accordance with the present invention. 

5 [0029] Depending on the conflict resolution rules or logic, information from any two 

smartcards can be combined or concatenated. In one example, for smartcards with the same 
primary account number (PAN) but different cardholders, program balances can be combined 
as described above. 

[0030] Moreover, the process of concatenating card images from an expired 

10 smartcard to a newly reissued smartcard can be tied to the activation function. 

[0031] Furthermore, the CMM also has a mechanism that detects and reports when 

the new smartcard is removed from the card acceptance device or card reader before 
completion of the RPI synchronization or replacement process and when the desired RPI has 
not been successfully downloaded and/or updated. If the new smartcard is removed before 
15 completion of the RPI synchronization or replacement process or the desired RPI has not 

been successfully downloaded and/or updated, the RPI of the new smartcard is considered to 
be "torn" or otherwise corrupted. The foregoing process could then be used to perform repair 
of the RPI on the new smartcard. 

[0032] FIGs. 2A and 2B further illustrate exemplary operations of the system 100 

20 according to one embodiment of the present invention. Referring to FIG. 2 A, at 202, an 
issuer of a smartcard initiates a smartcard replacement process by, amongst other things, 
issuing a new smartcard. At 204, the new smartcard is linked to the old smartcard. The two 
smartcards may be linked based on a common loyalty account, the cardholder, or some other 
criteria. The linking information is stored in the central database. At 206, the new smartcard 
25 is forwarded to the cardholder. 

[0033] At 208, when the cardholder selects the RPI synchronization or replacement 

option at a kiosk (or website). At 210, the application determines which of the two options 
has been selected. If the synchronization option has been selected, at 212, the application 
checks to see if the old smartcard is present in the card acceptance device or card reader and, 
30 if not, the application displays a request to the cardholder to insert the old smartcard. At 214, 
the application then determines if the old smartcard is valid. Such determination may be 
performed by authenticating the old smartcard. A person of ordinary skill will know of 



various well-know techniques and/or methods that can be used to perform the authentication. 
In addition, the old smartcard may not be valid for other reasons. For example, an authorized 
number of synchronizations with respect to the old smartcard have already been performed. 
If the old smartcard is not valid, an appropriate error message is displayed to the cardholder 
5 and the card issuer is contacted at 216. 

[0034] At 21 8, if the old smartcard is valid, then the application records the old 

smartcard's RPI. At 220, the application instructs the cardholder to insert the new smartcard 
into the card acceptance device or card reader. At 222, the application determines whether 
the new smartcard is valid for synchronization. The new smartcard may not be valid for 
10 synchronization for a number of reasons. For example, the new smartcard is not linked to the 
old smartcard. At 224, if the new smartcard is not valid for synchronization, an appropriate 
error message is displayed to the cardholder and the card issuer is contacted. 

[0035] Referring to FIG. 2B, at 226, the application then checks to see if the new 

smartcard has been used in a rewards transaction prior to the requested RPI synchronization. 

15 If the new smartcard has not been used in a rewards transaction, then at 228 the application 
downloads a copy of the previously stored RPI from the old smartcard onto the new 
smartcard. At 234, the application logs the RPI added to the new smartcard. At 236, the 
application transmits a record of the RPI synchronization process and a copy of the RPI 
currently stored on the new smartcard to the central database for archival and subsequent 

20 update purposes. 

[0036] If it is determined that the new smartcard has been used in a rewards 

transaction, then at 230 the application determines whether there is sufficient room on the 
new smartcard to store the additional information relating to the rewards transaction. If there 
is sufficient room, at 234 the application calculates the differences between the respective 

25 RPIs of the old and the new smartcards. Using such differences, the application then at 236 
performs the appropriate merge or concatenation and generates an updated RPI for the new 
smartcard. The merge or concatenation is performed based on certain rules and/or logic. If 
there is not sufficient room, i.e., if the combination of the two RPIs cannot be stored within 
the available internal memory of the new smartcard, the application then at 232 may provide 

30 the cardholder with a dialog box showing a list of all unique programs within both RPIs and 
enable the cardholder to select those programs that should be downloaded to the new 
smartcard. Alternatively, the application may provide the cardholder with the "best case" 
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selection of the programs that are recommended for inclusion on the new smartcard. In 
another example, for any duplicated program (i.e., a program that appears on both the old and 
the new smartcards), the application sums the program information, where appropriate, such 
as program balances and redemption count, before loading the program to the new smartcard. 

5 [0037] Once the merge or concatenation is completed, the application then similarly 

sends a record of the RPI synchronization process and a copy of the RPI currently stored on 
the new smartcard to the central database for archival and subsequent update purposes. 

[0038] Optionally, once the final RPI has been written to the new smartcard, the 

application may allow the cardholder to obtain a listing of the concatenated information 
10 including, for example, a list of rewards programs remaining on the new smartcard with the 
updated balances. 

[0039] Referring back to FIG. 2 A, if the RPI synchronization option is not selected, 

then at 242 the application determines whether the RPI replacement option is selected. If it is 
determined that the replacement option is selected, then at 244 the application instructs the 

15 cardholder to insert the new smartcard. At 246, the application then checks to determine 
whether the new smartcard is valid for replacement purposes. Similarly, the new smartcard 
may not be valid for any one of a number of reasons. For example, the new smartcard may 
not be authenticated because the new smartcard is not linked to any old smartcard, or an 
authorized number of replacements have already been performed. If the new smartcard is not 

20 valid, then at 216 an appropriate message is displayed to the cardholder and the card issuer is 
contacted. 

[0040] If the new smartcard is valid, then at 248 the application downloads a desired 

copy of an RPI (which generally is a copy of an RPI from the old smartcard) from the central 
database and temporarily stores that RPI in its internal memory. The same logic then follows 
25 as shown in FIG. 2B. 

[0041] The present invention as described herein provides the capability for the 

cardholder to retain earned rewards by interactively performing the tasks of synchronizing, 
replacing or concatenating the RPI of his/her new smartcard with that of the old smartcard, 
regardless of whether the old smartcard is being replaced due to its loss, theft, re-issuance due 
30 to expiration or damage. 
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[0042] The present invention as described herein is applicable to various 

environments. In one environment, the present invention is used in connection with retail 
merchant and service organization payment systems that interface to a portable device such 
as a smartcard in the context of a transaction where the cardholder is provided with variable 
incentives or rewards when specific, desired purchase behaviors are performed. 

[0043] The present invention can also be deployed in an environment where the 

interface between the portable device and the card acceptance device at an acceptance point is 
performed offline and critical rewards data, programs and/or parameters are electronically 
stored within the portable device in the form of an image. The present invention can be used 
in connection with a rewards/loyalty system that is designed in a network centric model, 
wherein an unrestricted number of cardholders, card issuers, acceptance point operators 
(merchants) and rewards sponsors may participate in a one common rewards program. 

[0044] The present invention may also be implemented in different combinations of 

hardware and software than the ones described. Based on the disclosure and teachings 
provided herein, a person of ordinary skill in the art will know of other ways and/or methods 
to implement the present invention. 

[0045] It should be understood that the embodiments provided are illustrative and not 

restrictive. Various other modifications are possible within the scope of the invention 
claimed. Moreover, while the description of the different embodiments are provided in the 
context of a loyalty program, a person of ordinary skill in the art would appreciate how to 
utilize the present invention in other applications or context where combining of information 
may be desirable. 
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